Desk Review — #1941 (rename "Display name" → "Name" + auto-derive Name from email)

Verdict: ✅ READY TO MERGE.

Reviewed the full implementation on tale/xs75btd3z121y0qdggwak1e0wn897pba (not just the diff lines), across correctness/robustness/elegance/tests/boundaries, with a confirmation pass on every candidate finding.

CI & tests

• CI: all green. Every check on the PR passes (Type check, Lint, Format, Knip, Unit, Build platform, all 16 Playwright platform shards, Smoke, Storybook, etc.). The only non-passing jobs are fork-only (Smoke test (fork PR), Validate images (fork PR), Web container test, Trivy) which correctly skip on a same-repo PR.
• Ran locally: bunx vitest --run --project server lib/utils/derive-name-from-email.test.ts → 21/21 pass. bunx vitest --run --config vitest.ui.config.ts member-add-dialog → 3/3 pass.

What's correct

• deriveNameFromEmail (lib/utils) is well-factored, total (never throws — '' on any non-string/empty input), unicode- and locale-aware, with a 21-case co-located test covering separators, +tag aliases, digit stripping, camelCase, initials, numeric-only, unicode, and a 200-char input.
• Wiring into all three required surfaces is sound: onboarding signup (account-step.tsx), member-add (member-add-dialog.tsx), and account settings (account-form.tsx). The nameEditedRef "stop overwriting once the user edits" pattern is correct; in the reusable member dialog the ref is reset on every path that re-opens a fresh form (submit-success, handleClose, handleOpenChange — and every credentials-dialog dismissal funnels through handleClose).
• Rename is complete for the profile concept across en/de/fr message catalogs (including the new auth.name / auth.namePlaceholder / auth.validation.nameRequired keys, all genuinely translated). Remaining "Display name" strings belong to unrelated concepts (providers, agents, token sources) and are correctly out of scope. The aria-label + E2E (settings.spec.ts, getByRole('textbox', { name: t('settings.account.profile.name') })) stay consistent after the id rename display-name→name.
• Security clean: derived names render only as React text / i18n interpolation (member-table, user-button, mention-text, avatar initials) — no dangerouslySetInnerHTML, no PII logging.
• Docs (preferences.md en/de/fr) updated accurately and even corrected a stale pre-existing "saves on blur" claim.

Non-blocking observations (optional follow-ups, none required for merge)

1. Empty derivation for +-prefixed local-parts (account-step.tsx): a legal-but-unusual email like +tag@example.com derives to ''; since Name is required, the form shows a clear "Name is required" error until the user types one. This is the correct required-field fallback (verified the error renders), not a dead-end — noting only for awareness.
2. name === email legacy heuristic (account-form.tsx): a user who deliberately sets their display name equal to their email would see a derived suggestion offered on reload. Rare, by-design migration tradeoff; the suggestion is editable and not auto-saved.
3. Duplicated nameEditedRef + wrapped-onChange + email-watching useEffect across account-step.tsx and member-add-dialog.tsx — a small, acceptable duplication that could become a shared useEmailDerivedName hook later.
4. Component-level test coverage gap: the pure util is well-tested and E2E covers the rename, but the auto-derive wiring / nameEditedRef / legacy name===email branches have no component test. Minor.
5. The tail commit style: format issue-desk desk-process.json (pre-existing drift from #2122) is unrelated churn that ideally lives in its own PR; harmless.

None of the above blocks merge.